home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / std / c / 226 < prev    next >
Text File  |  1996-08-06  |  5KB  |  121 lines

  1. Path: newshost.lanl.gov!tanmoy
  2. From: tanmoy@qcd.lanl.gov (Tanmoy Bhattacharya)
  3. Newsgroups: comp.lang.c,comp.std.c
  4. Subject: Re: Integral conversion e.t.c. (was: Re: Hungarian notation)
  5. Date: 30 Jan 1996 01:30:41 GMT
  6. Organization: Los Alamos National Laboratory
  7. Message-ID: <TANMOY.96Jan29183041@qcd.lanl.gov>
  8. References: <30C40F77.53B5@swsbbs.com> <SPENCER.96Jan22113215@zorgon.ERA.COM>
  9.     <KANZE.96Jan26164833@gabi.gabi-soft.fr> <DLtABq.Fzu@mv.mv.com>
  10.     <4edqh2$rvl@solutions.solon.com>
  11.     <KANZE.96Jan29121956@slsvewt.lts.sel.alcatel.de>
  12.     <TANMOY.96Jan29090518@qcd.lanl.gov>
  13.     <KANZE.96Jan29201312@slsvewt.lts.sel.alcatel.de>
  14. NNTP-Posting-Host: qcd.lanl.gov
  15. Mime-Version: 1.0
  16. Content-Type: text
  17. In-reply-to: kanze@lts.sel.alcatel.de's message of 29 Jan 1996 19:13:12 GMT
  18.  
  19. In article <KANZE.96Jan29201312@slsvewt.lts.sel.alcatel.de>
  20. kanze@lts.sel.alcatel.de (James Kanze US/ESC 60/3/141 #40763) writes: 
  21. <snip>
  22.    I agree, but...
  23.  
  24.    Try naming a global function read, and see what happens (on most
  25.    compilers, anyway).  In fact, the Posix standard requires it, and
  26.  
  27. What should happen? It compiles perfectly and produces the expected
  28. answer! 
  29.  
  30. tanmoy@qcd:tsh21540:48.0>>cat j.c
  31. #include <stdio.h>
  32. int read(int x) { return x + 1; }
  33. int main(void) {
  34.   return !printf("%d\n",read(1));
  35. }
  36. tanmoy@qcd:tsh21540:49.0>>glintc j.c
  37. tanmoy@qcd:tsh21540:50.0>>a.out
  38. 2
  39. tanmoy@qcd:tsh21540:51.0>>uname -a
  40. SunOS qcd 4.1.4 2 sun4m
  41.  
  42. and also
  43.  
  44. tanmoy@qcd:tsh21540:59.0>>cat k.c
  45. #include <stdio.h>
  46. int read(x) { return x + 1; }
  47. int main() {
  48.   return !printf("%d\n",read(1));
  49. }
  50. tanmoy@qcd:tsh21540:60.0>>cc k.c
  51. tanmoy@qcd:tsh21540:61.0>>a.out
  52. 2
  53.  
  54. (By the way, your assertion is correct: in general few compilers are
  55. completely conforming. My examples don't work if I change read to a
  56. write :-)
  57.  
  58.    thus, you cannot be Posix compliant without encroaching upon the user
  59.    name space.  (For example.  I'm sure that most other systems will have
  60.    similar constraints.)
  61.  
  62. This is incorrect. What the compiler has to do is to ensure that posix
  63. definitions are not seen unless I invoke undefined behaviour (e.g. by
  64. #including a posix specific header or leaving an external symbol
  65. undefined). Pretty easy to arrange usually (if the linker helps by not
  66. loading from the library something that has already been satisfied,
  67. for example, and no library routine calls a routine in user name
  68. space: if necessary they call a routine which is, separately, wrapped
  69. by a name in the user space): but old machines (like SunOS) have not
  70. yet done this.
  71.  
  72.    |> For example, assuming that the concept of a far pointer is truly
  73.    |> required (It is really an exceptional circumstance which truly
  74.    |> _requires_ it; a compiler should usually figure out whether a near or
  75.    |> far pointer will work better: but that is a separate discussion), a
  76.    |> compiler should invent a keyword in the implementation name space
  77.    |> (e.g. __far) for it. It may provide a non-default switch
  78.    |> /backward-compatible to allow it to recognize far as a keyword and
  79.    |> treat it as a syntax error if used as a variable name.
  80.  
  81.    |> But I agree that discussions in comp.lang.c should also take care of
  82.    |> current realities, even if those realities are fossils of an era long
  83.    |> past, frozen in time only by the arrogant ignorance of a large body of
  84.    |> users with a narrow view to the future.
  85.  
  86.    Well, I'm not sure that I'd consider Posix a fossil of an era long
  87.    past, although it certainly reflects a long history.
  88.  
  89. As I said, almost no Posix extension requires diagnostic. It usually
  90. specifies meaning for constructs undefined in C.
  91.  
  92.    I'm not sure where to draw the line.  Discussions of `read' certainly
  93.    don't belong in c.l.c.  But simply telling someone that his system is
  94.    broken because printf stopped working when he declared a global read
  95.    is not going to help anyone, even if, strictly speaking, it is true
  96.    according to the standard.
  97.  
  98.    I may be oversensitivized to this problem.  My usual hang-outs are the
  99.    C++ groups.  Given the speed the C++ standard has evolved, there is no
  100.    such thing as a conforming compiler, and most people have to get their
  101.    programs working now, and not in 10 years time.  As a result, we do
  102.    spend a lot of time talking about compiler idiocyncracies.
  103.  
  104. As far as comp.lang.c is concerned, I would say that pointing out to
  105. people that their compiler is broken because it does not allow them an
  106. external function called write is good enough. It tells them:
  107.  1) The compiler should: they should complain to the vendor.
  108.  2) The temporary fix is to not name the function write.
  109.  
  110. Isn't that good enough?
  111.  
  112. Cheers
  113. Tanmoy
  114. --
  115. tanmoy@qcd.lanl.gov(128.165.23.46) DECNET: BETA::"tanmoy@lanl.gov"(1.218=1242)
  116. Tanmoy Bhattacharya O:T-8(MS B285)LANL,NM87545 H:#9,3000,Trinity Drive,NM87544
  117. Others see <gopher://yaleinfo.yale.edu:7700/00/Internet-People/internet-mail>,
  118. <http://alpha.acast.nova.edu/cgi-bin/inmgq.pl>or<ftp://csd4.csd.uwm.edu/pub/
  119. internetwork-mail-guide>. -- <http://nqcd.lanl.gov/people/tanmoy/tanmoy.html>
  120. fax: 1 (505) 665 3003   voice: 1 (505) 665 4733    [ Home: 1 (505) 662 5596 ]
  121.